TIPS FOR THE TOP
by Gavin B Monk
from Your Spectrum 10 (Dec'84/Jan'85)

Contributions to Program Power have been arriving at a steady
rate over the Summer months and the quality has improved
considerably since my few suggestions in issue 3.
	What I'm doing this month is looking through all of the listings
we've published in YS so far, picking out the good bits, adding a
few little extras of my own - and presenting you with a series of
nine routines. The REM statements may, of course, be omitted,
but personally I'd suggest that you leave them in.
	The routines use lines 1-30 and lines 8000-9999 which should
still leave you plenty of room for your own program. They offer the
following facilities: flashy border, happy tune, UDG generator,
display lives, end of game/high score, string input editor, case
converter, user-defined keys and valid answer checker. You'll find
a good explanation of each routine as it's listed in the following
pages. The best thing to do is to type the whole program in and
then, using the annotations for each routine, play around with each
section until you understand how each one works.

Lines 1-6
Cause a jump past the 'flashy border' routine so that the
command RUN will still your program in motion.

Lines 7-20
This routine is placed at the start of the program to ensure it
runs fast and produces a steady display. Called by GO SUB
10, this routine will cause a spectrum of stripes to be
displayed across the top half of the border, while waiting for a
key press. When you leave the routine, the border colour will
revert to white. The PAUSE 1 statement matches the program
speed with the TV scan.

Lines 30-31
You've got lines 30-7996 to write your own program - all
you have to do is call the relevant routine you need to spice up
the proceedings.

Lines 7997-80160
Use the 'happy tune' routine when you want to give a reward
for good play ... perhaps to signal a new high score, extra
life or a switch to a new level. The routine produces an eight-
note tune from the data in line 8050. You can call it by GO SUB
8000; note that it uses the variables 'i', 't' and 'n'.

Lines 8097-8150
This routine provides a simple user-defined graphics
generator. First plan your UDG graphics, either on graph
paper or with a suitable software package, and then make a
note of the values as detailed in the Spectrum manual. Now
change the 'u' in line 8110 so that only the number of
graphics required will be set up - for instance, 'd' will allow
graphics a-d to be defined. Place the data for each character
in lines 8160-8180 and, to set up the UDGs, call the routine
with GO SUB 8100.

Lines 8159-8180
These lines have been set aside for you to allocate the data
you'll need to define each of the UDGs in your program.

Lines 8197-8210
String handling on the Spectrum is very different to that
found on all non-Sinclair impedimenta, but did you know that
items inside quotes in PRINT statements can also be sliced?
"What use is this?", I hear you wonder. Well, if you define a
UDG character to represent your playing character, then you
can quite easily have a string of characters displaying the
number of lives anywhere on the screen. Set 'x' and 'y' to
represent the co-ordinates of the screen position required
and let 'li' equal the number of lives. Now, call the routine
with GO SUB 8200 and you'll find that the remaining number
of lives will be printed up on-screen in the form of a row of
player characters - Pacmen, for example.

Lines 8297-8420
This very handy routine is all that's needed to convey the sad
message: "I'm sorry but your game is over". It also requires
the input string editor (see the next routine), the 'happy tune'
routine, and variables 'sc' (score) and 'hs' (high score) to be
set. The routine is called by GO SUB 8300, and on return from
the routine the high score name will be stored in h$. The
maximum name length is set to five characters in line 8400,
but this can be adjusted to suit.

Lines 8497-8690
If you've ever wanted to get rid of those keywords and
punctuation marks accepted by the INPUT statement, then
this one's for you. This input string editor allows screen line
21 to be used for alphabetical inputs of up to 32 characters.
The input is checked that it doesn't contain keywords and all
the other yuck that the normal INPUT accepts. The routine is
quite long and you must note that it uses a$ (stores input), k$
(stores the key pressed) and 'co' (code of the key pressed). It
all works by checking the code of the key pressed to see if it's
in the required range; it it's the Enter or Delete key, then the
appropriate jump is made to a routine which adds the key to
the entry, stops the input or deletes the key from the input.
This routine should be especially useful for adventure
programmers.

Lines 8697-8850
Here's another routine for the adventure freaks out there who
are worried about the Caps lock being switched on or off
during an entry. Everybody, of course, knows that POKE
23658,8/0 turns it on or off respectively. The trouble is, doing
this doesn't stop someone turning it off/on during a listing.
The answer is to change the limits in line 8590 of the input
routine above, or use this two-case converter routine. To
convert a$ to upper case use GO SUB 8700 - to lower case,
GO SUB 8800. Note that the variables used are 'i' and 'co'.

Lines 8897-9130
Many commercial games now have a user-defined key option
- the final solution for complaints about the control key
layout. But here, another hidden benefit is that the Interface 2
and AGF joystick protocols can be used. This routine returns
the keys selected in m$ (the movement string!) in the order
given in the data statement at line 9130. The first digit in this
statement is the number of keys required and the strings
following this detail the purpose of each; checks are made to
ensure the same key is not used twice. The following
variables are used by the routine; nk (number of keys
required); d$ (direction of required key); and k$ (key
pressed). The 'flashy border' routine is also used so that a
key press is waited for, once all the required keys have been
entered. To add this feature to your game just GO SUB 8900.
To check for movement in a game, all you now need is
something rather like this:
	IF INKEY$=m$(3) THEN ...: REM
	detects 'up' movement if using the given data

Lines 9497-9600
This routine checks for a valid answer, but to be quite honest
this is not so much a routine ... more a collection of hints.
Line 9500 asks for an answer to be input and this answer is
then taken in a$; lines 9510 and 9550 check it for length (up to
five characters) and invalid characters. If one of these is
found, a message is flashed up briefly on the input line - and
then the input prompt reappears once more. By changing the
limits in line 9530, checks can be made against numeric or
character inputs so that the VAL or VAL$ functions can be
used.
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